As computers and affiliated storage capabilities progress, the underlying filesystem structure can play a role in an operating system's performance and reliability. In general, a file system includes a number of objects, such as files, that are stored on a computer system along with the metadata that relates to the arrangement and location of these files. Within UNIX-variant systems, the filesystem is often viewed as a hierarchical arrangement of directories and files stemming from a root directory. Such an arrangement is often viewed as an inverted tree where directories, sub-directories and files extend downward from the root directory ultimately to leaf-nodes. Within modern graphical user interface based operating systems, the filesystem is often viewed as an arrangement of folders that may or may not be hierarchically arranged.
The actual internal structure of the filesystem and its implementation is usually hidden from the user of the computer system. For example, early UNIX filesystems included a directory structure that resembled a table having matched pairs of names and inode numbers. The inode numbers themselves, pointed to a respective entry in an inode table that allowed the operating system to find and retrieve the file from a physical storage medium. Thus, the files and directories were not actually arranged hierarchically on the physical medium where they were stored; but, instead, the filesystem structure provided that appearance to the user. In general then, a directory is viewed as a table of entries with each entry including an object name and an “anchor” point. By accessing the anchor point, an operating system can locate an object referred to in a directory entry.
As operating systems and filesystems have developed and changed, a need has arisen for customers to be able to change filesystem structures (i.e., change from one type of filesystem to another type) to receive the benefits of that development. For example, over the course of development in one popular operating system, the filesystem type has changed from FAT16, to FAT32 and to NTFS. While it is possible to require customers to completely re-install all their software and files when a new filesystem type is introduced, doing so would have a number of drawbacks. The cost, time and complexity of such an undertaking would cause many customers to avoid the upgrade process even though it might be beneficial.
Accordingly, automatic methods have been developed for updating filesystems from one type to another to make the conversion process easier for customers. Each different operating system has its own filesystem conversion process that has been developed. For example, HP-UX, Solaris, AS/400, and Windows, each supported a particular filesystem and directory structure that, when updated, required a specific conversion program to update the filesystem type or structure. In the past, all of these different filesystem conversion processes have had a significant drawback, they have required the user to shutdown the filesystem while upgrading the filesystem. Thus, when converting a filesystem, a user is unable to perform other operations with the affected computer system which leads to operational downtime and often increased costs.
One alternative way to convert filesystems is known as “first-touch” conversion. This method of filesystem conversion avoids shutting down the entire filesystem as described above, but introduces its own set of problems. In a first-touch process, the operating system recognizes when a file object is “touched” for the first time after a new filesystem type is available. The operating system then stops its processing and converts the filesystem object to the new filesystem type. This type of conversion process results in great delays and possibly errors when accessing certain file objects. For example, if a directory having a large number of files is opened for reading, the open process is suspended until that entire directory is converted to the new filesystem type. Thus, the user will see degraded performance each time a filesystem object needing to be converted is first encountered. Secondly, this process logic does not ensure that all file objects within a filesystem are converted. Only those that are touched will be converted. Therefore, the operating system must continue to support both types of filesystem structures even if one type is less efficient than the other.
One specific problem that may be encountered with converting a filesystem while it remains in operation and active is that during the conversion process there may be the need to support a particular filesystem object in both an old type of filesystem object and a new type of filesystem object. Present operating systems do not provide such support. Some modern operating systems do support different filesystem types simultaneously but this support is for different branches of the filesystem tree or for different objects. For example, all objects under one branch may be of a first filesystem type and all the objects of another branch are implemented as another filesystem type. This support, however, does not extend to a particular filesystem object being supported under different filesystem types.
Thus, there is an unmet need for a filesystem structure and operating system that permits the filesystem type to be converted while the filesystem remains active so that operations and access to the filesystem are not interrupted. Additionally, there remains a particular need for an operating system that simultaneously supports a filesystem object within different filesystem implementations.